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ABSTRACT 


This paper presents evidence that the United States military and intelligence 
communities have a history of focusing on hardware while neglecting the need to 
examine processes. It proceeds to illustrate that current ORS initiatives appear to 
be doing the same. A case study is presented highlighting the ramifications of 
neglecting processes when trying to improve operations. ISR tasking is 
examined, including the potential that politics exerts influences upon the process. 
The concept of Operationally Responsive Tasking is presented, not as a specific 
methodology for tasking satellites, but as a generalized model offering insight 
into the ramifications of certain tasking process design decisions. Specific 
constructs introduced include Tasking Depth, Tasking Breadth, Petitioner 
Tasking, and Supplicant Tasking. The model is shown to offer insight into tasking 
process modifications and their impacts. The potential for the Virtual Mission 
Operations Center software to implement the ability to modify a tasking process 
on-demand is discussed. VMOC is shown to be a sound platform for 
implementing the basic concepts of ORT, including reducing the expertise 
required to utilize ISR satellites through the use of ontologies. Responsiveness is 
shown to be a limited resource that is tied to the capacity of collection assets. 
Specific recommendations for further research into mathematical models to guide 
tasking process decisions are offered. 
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I. INTRODUCTION 


Operationally Responsive Space (ORS) has captured the attention of the 
space community. Several ORS satellites have been launched, the ORS Office 
has been created, and a plethora of articles and papers have been written. A 
search through articles dealing with ORS reveals that the preponderance of them 
focus upon hardware, its associated software, or the process for acquiring them. 
What appears to be conspicuously absent is an attempt to better understand and 
improve the tasking process for current and future satellites. Such an endeavor is 
critical to ensure ORS can deliver increased support for the Joint Force 
Commander as specified in the Department of Defense (DoD) Plan for 
Operationally Responsive Space [1]. 

This paper will present evidence that this focus upon hardware, software, 
and acquisition without commensurate emphasis upon developing more 
responsive tasking processes creates an unbalanced approach. Additionally, it 
will touch on the potentially negative impact that politics may have on the 
utilization of ISR satellites. This negative impact may extend to ORS as a whole if 
measures are not developed to insulate the ORS community from the disruptive 
influences of politics. The concept of Operationally Responsive Tasking, or ORT, 
will be introduced and discussed. While not a specific tasking methodology, ORT 
seeks to present standardized ways in which tasking processes may be analyzed 
and compared. Specific attention is placed upon identifying privileged and 
disadvantaged users of a tasking process. By avoiding the development of highly 
specific constraints in favor of focusing upon objective measures of 
responsiveness, ORT may have usefulness in assessing tasking processes for 
multiple satellite systems in addition to ORS. 
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II. A HISTORY OF HARDWARE FIXATION 


Hardware, not alternative approaches to responsiveness, has been very 
much the hallmark of ORS to date. Lt Col Scott Larrimore captured this issue 
effectively in his paper Operationally Responsive Space: A New Paradigm or 
Another False Start : 

Operationally Responsive Space has focused on a material solution 
to solve the perceived need to better support joint forces from 
space. However, this view is a bit short sighted. If needed, there 
are many other tactics and procedures space commanders could 
enact to better support tactical forces in emerging crises. [2] 

This hardware fixation is not a new phenomenon. Indications that the 
United States has a history of focusing upon intelligence hardware, to the 
detriment of processing and non-hardware aspects of intelligence production, 
can be found in the Congressional record going back at least as far as 1996 [3]. 
Major Shane Hamilton captured this issue well in the following excerpt from 
Balanced Insanity: An Argument for the Inclusion of Tasking, Processing, 
Exploitation, and Dissemination in Future Security Assistance Unmanned Aerial 
Vehicle Programs. 

As the United States increasingly depends on its airborne 
intelligence collection systems, too much of the focus traditionally 
has been placed on the platforms themselves to the neglect of the 
supporting intelligence architecture that makes the intelligence 
platforms effective. [4] 

The focus on hardware appears to extend beyond the ORS and 
intelligence communities, with indications that it is a larger DoD issue. Sheehan 
writes in his paper The Military Missions and Means Framework that certain DoD 
transformation initiatives: 

Focus largely on the material-the physical means needed for 
successful military prosecution-without adequate consideration for 
(or linkage to) the missions--the end actions that must be 
accomplished to meet objectives. [5] 
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These accusations transcend the notional. Specific intelligence satellite 
programs have been identified as having neglected the important aspects of 
tasking and follow-on processing. The Independent Commission on the National 
Imagery and Mapping Agency (predecessor of the National Geospatial- 
Intelligence Agency) found that the Future Imagery Architecture did not place 
enough resources against the issues of ensuring proper tasking [6]. The 
commission went further, indicting the entire Intelligence Community with the 
following excerpt from their report: 

The Commission validates the charge that the Intelligence 
Community is ‘collection centric,’ thinking first of developing and 
operating sophisticated technical collection systems such as 
reconnaissance satellites, and only as an afterthought preparing to 
properly task the systems and to process, exploit, and disseminate 
the collected products. [6] 

Combined, these references underscore the assertion that a tendency to 
emphasize hardware over processes exists in the military and intelligence 
communities. There are strong indications that this continues within the ORS 
community. 

A. ORS TASKING MECHANISMS 

The Virtual Mission Operations Center, or VMOC, is a web-based 
hardware and software system offering the capability to manage the tasking of 
ORS assets in a network-centric environment. It has been selected by the ORS 
Office as their primary payload planning, tasking, scheduling and visualization 
tool [7, p. 1], Figure 1 depicts the tasking methodology for VMOC. 
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Figure 1. VMOC Tasking Diagram (From Virtual Mission Operations Center 
and ORS Ground System Enterprise [8]) 


The diagram identifies generalized pathways for information. An 
information request flows from the warfighter where it is passed through several 
offices making use of software tools for tasking, apportionment, and payload 
management. Residing behind everything is a reference to the GIG, or Global 
Information Grid. Finally, an ORS constellation is depicted. This diagram focuses 
heavily upon the hardware and infrastructure of the ORS tasking process, but the 
processes utilized by the COCOM/JFC to manage information requests from the 
warfighter remain undefined and apparently untouched. 

VMOC provides the necessary tools and communications to allow ORS 
assets to be tasked with few, if any, changes to current processes. VMOC has 
been envisioned as receiving tasking in a fashion similar to other JFC assets 
such as a U-2 or Rivet Joint aircraft. It includes functionality to interface directly 
with existing tasking tools [8] at the JFC level. This level of integration allows 
ORS assets to be plugged into existing processes and treated as just another 
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collection asset. Such integration obviously required much attention to hardware, 
software, and infrastructure. It also suggests that existing processes for 
managing warfighter requests for support were left largely intact [8, 9]. 

The introduction of hardware and software into an existing process will 
inevitably require some changes to process. Such changes are reactive in nature 
and may or may not improve overall operations. This paper will focus upon 
proactive process changes engineered to have a direct impact upon overall 
performance, rather than process changes designed to accommodate the 
introduction of hardware, software, and infrastructure modifications. The ORS 
tasking processes appear to be largely driven by hardware and software 
innovation. Little direct work has been accomplished on development of tasking 
models focused upon improving responsiveness for lower echelon units. ORS is 
continuing the tradition of improving hardware and infrastructure while largely 
ignoring process improvements. As will be shown, such a course can undermine 
or nullify efforts to improve operations. 

B. CASE STUDY: ST. JOSEPH S HOSPITAL EMERGENCY 

DEPARTMENT 

It appears that the United States has a long history of being enamored 
with technology and partially neglectful of the processes necessary to ensure that 
technology is used properly. This history of focusing on collection technology and 
hardware appears to be continuing within the ORS community. The question that 
must be asked is, “Does this pose a problem for the success of ORS?” 
Unfortunately, the answer to this question is not entirely clear without an actual 
example of how one needs to consider processes, not just hardware and 
infrastructure. Within the space and intelligence communities, there are few if any 
unclassified examples available for examination. To find an example, we will turn 
to emergency medicine. There is a growing realization that overcrowding in 
emergency departments, which has traditionally been addressed through 
infrastructure upgrades, may best be addressed by modifying core processes 
[10]. The lessons learned by a hospital emergency department in Maryland may 
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hold relevance in a discussion of the potential pitfalls of the current ORS 
hardware emphasis. This particular emergency department specifically focused 
upon solving a performance and responsiveness problem using upgrades to 
hardware and infrastructure rather than process improvements. 

The St. Joseph Hospital Emergency Department was dissatisfied with 
their patient throughput metrics, an important gauge of their overall effectiveness 
and, arguably, their responsiveness [11]. Given the age and state of their 
facilities, which had 20 beds, it was determined that an infrastructure upgrade 
that included doubling their available beds would solve the problem. The upgrade 
was authorized. After the facility had been completely renovated into a state-of- 
the-art, much larger center with 40 beds, the department personnel expected to 
see improvement in their throughput. The exact opposite happened. They saw no 
improvement. Worse, only months after the upgrade, their performance metrics 
reached all-time lows [11, p. 1 ]. 

The emergency department at St. Joseph’s was forced to look at other 
options to improve their performance metrics. Clearly, their attempt to solve 
issues using material upgrades had no effect, so they turned to their processes. 
In particular, they looked at one of their most entrenched and unquestioned 
processes: triage. Triage, in its simplest sense, is a prioritization process [12] 
which logically flows into and complements tasking processes. In emergency 
medicine, patients are subjected to triage (prioritization), and then the available 
resources are allocated (tasked) to those patients based upon the assigned 
priority. The resources may include such things as beds and on-duty physicians 
[ 11 ]- 

As they examined their triage processes, they found that inadequacies 

and rigidity in the application of the triage system could be at the root of their 

performance/responsiveness issues. Due to the established nature of emergency 

triage within the medical community, this concept was met with resistance by the 

emergency department staff. The staff had been trained in triage for their entire 

careers. They viewed the recommendations for change to the triage methodology 
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as a radical approach. Artful and carefully planned presentations, including a 
retreat for key members of the emergency department staff, were required to win 
buy-in for the new procedures [11, p. 3]. Once fully implemented, the new 
processes yielded significant improvements in the performance and 
responsiveness of the emergency department. Several months after the 
implementation of the new processes, their key metrics had improved 
dramatically [11, p. 5]. 

The experience at St. Joseph’s Emergency Department has several 
potentially useful lessons for the ORS community. First, material solutions to 
performance issues may not necessarily yield the desired improvements in 
performance. This can be seen from the fact that, while St. Joseph’s upgraded 
their facilities and doubled their available beds, their performance in patient 
throughput did not improve. The upgrades increased their patient throughput 
potential, but their process issues prevented them from performing to that 
potential. Second, process improvements are key to utilizing all of the potential 
offered by hardware and infrastructure. Improvements to processes may account 
for a significant boost in performance. St. Joseph’s decision to significantly alter 
their triage procedures resulted in major improvements for their ability to serve 
more customers with the same resources. Process improvements, however, 
cannot deliver performance in excess of the capacity of hardware and 
infrastructure. Third, process change initiatives may be met with community 
resistance and must be carefully crafted and presented in order for that 
community to agree to the change. In the case of St. Joseph’s, management 
personnel carefully targeted the supervisors with their plans so that the process 
changes would be adopted [11]. 

St. Joseph’s experience shows that process changes may in some 
instances be more effective in improving performance than infrastructure and 
hardware changes. The commonality between emergency medicine and satellite- 
based intelligence collection lies in their efforts to accomplish a mission with 
potentially limited resources [13], [14]. The use of triage, the practice of allocating 

8 



limited resources to best effect using a prioritization process [15], is a logical 
approach when striving to accomplish a resource-intensive mission. A tasking 
system for ORS satellites must also use a logical approach when it strives to 
accomplish its mission. At the basic level, there is commonality between ORS 
and emergency medicine and one can apply the lessons learned from the case 
study. As we look further into tasking processes, we will find that military 
commanders believe the authority to directly task satellites can offer them control 
over ISR asset usage and help to address their concerns about receipt of 
required intelligence. 
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III. ISR TASKING 


One impetus for looking at the issue of tasking is the perceived desire of 
combat commanders to exercise tasking authority over ISR assets. This desire 
appears to be shared by commanders at all levels. Army Lieutenant General 
Kevin T. Campbell puts forth some very interesting points of view in his article 
The Warfighter’s Perspective on Space Support [16]. He wastes no time in 
pointing out that space support does not reach the “lower echelon units- 
those closest to the fight.” He goes on to define the three attributes needed 
in warfighter-supporting space units: assuredness, persistence, and 
responsiveness. He defines assuredness as the receipt of the products and 
services needed. Persistence is summed up as continual availability of assets 
when needed. Responsiveness is defined as “the ability to task an asset in real 
time for rapid delivery of information to the troops in contact [16, p. 5].” This direct 
reference to tasking as a cornerstone of responsiveness reveals his recognition 
of the power inherent in the authority to task satellites. Given the power of 
tasking authority, it is important to assess the appropriate level at which that 
authority should be exercised. Identifying the actual processes for controlling ISR 
assets is difficult for outsiders due to a lack of easy insight into satellite tasking. 

A. SATELLITE TRIAGE 

The specific tasking processes for ISR satellites are largely cloaked in 
secrecy. There is scant information available in open media or unclassified 
documents to illuminate the established processes that are applied to make 
decisions about how to task ISR satellites. What we do know is that demand for 
ISR products outstrips the available capacity [14], Under such a constraint, it is 
safe to assume that the processes in place must include decisions about which 
requests for support out-prioritize others. Such an assessment logically leads to 
a decision about which requests are actually assigned to satellites, making it a 
form of triage. While triage is consistently viewed as a process that is medical in 
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nature, the term itself applies to any situation in which a person or organization 
must manage limited resources and apply them for best effect in the face of a 
situation where demand outstrips supply [15]. A search of literature will show that 
triage is used in varied fields including the mortgage industry [17], software 
development [18], and water resource management [15]. 

It is in the application of triage to medicine that we can find the most 
parallels to the problems of managing space assets. The simplest form of 
medical triage is discussed in the literature as a basic three-level prioritization 
that includes assessing each patient on a scale that designates their likelihood of 
recovery: those who will likely recover regardless of medical treatment, those 
who will die regardless of medical treatment, and those who will recover only with 
immediate medical treatment [19]. Variations on this basic process have been 
developed over the years, including greater numbers of priorities (5 or 7) and 
other improvements [19], but the general idea remains. 

The process is focused upon managing a demand for services that 
outstrips the supply of those services, much like the situation with ISR satellites. 
The typical application of such a system is to take a request for service and 
assign it to a service provider based upon a priority. If we consider the 
application of this system to ORS, we can assume that a military customer might 
have their request for support assigned to a satellite, but only after the request is 
passed through a system for prioritization and approval. We will call this form of 
tasking Reactive Tasking, since no action occurs until a request arrives, receives 
a priority, and merits action based upon that priority. Conversely, we can envision 
a tasking system in which a need for resources is anticipated, and a satellite is 
assigned to a customer to be ready for use when the customer identifies a task 
for the satellite. We will call this Proactive Tasking. 

In proactive tasking, the satellite will be as responsive as possible to the 

assigned unit, within its design and orbital limits. This approach carries a risk that 

the customer will not actually require the satellite, which has now been removed 

from the service of other potential customers. Such a method of managing 
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collection assets runs counter to established intelligence community practice, 
which loathes any loss of collection capability. The intelligence community takes 
very seriously the need to ensure that collection opportunities are not wasted. 
This is accomplished by running all requests for information through an extensive 
process that compares recent collection against currently available information 
[20], [4, p. 57], The idea is to avoid committing collection assets to obtain 
information that is already available. A reasonable exception to this approach 
involves a commander who wants to know what is happening right now, for which 
previous collection will be of little use. Committing an asset would be the only 
way to obtain the information. It is in such situations that granting tasking 
authority to a lower echelon unit makes sense. The need for immediate 
information indicates that it is time sensitive and should be pursued without 
delay. It is in the anticipation of such instances that Proactive Tasking should be 
considered. Proactive tasking is the better model for satisfying Lieutenant 
General Campbell’s definition of responsiveness, as once a satellite is assigned 
to a unit it will be available for tasking without potential interference from other 
units who might be competing for the use of the asset. Problems may arise when 
using proactive tasking. One of these is the need for expertise at the unit, which 
has received the authority to task the asset proactively. 

B. THE NEED FOR EXPERTISE 

The Joint Reconnaissance Platform (JRP) experiment highlighted the 
potential pitfalls of using proactive tasking, specifically by delegating tasking 
authority over a space asset to a combatant command. In this experiment, an 
operational space capability was proactively tasked to a combatant commander, 
to be available for the specific uses determined by that commander. Among the 
lessons learned from the JRP experiment was that theater collection managers 
were unable to immediately begin tasking to full effect, thus delaying JRP’s ability 
to fully support the warfighter [21]. The tasking learning curve for the JRP asset 
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was unexpectedly steep. These learning curve problems highlight the need to 
ensure that ORS tasking processes and methodologies are carefully considered 
prior to delivering a capability. 

For any tasking to be effective, those charged with tasking the asset must 
be armed with the knowledge and understanding necessary to be able to 
properly utilize the asset. The greater the gap between the knowledge level of 
those tasking the asset and the requisite knowledge level to properly task the 
asset, the lower the likelihood that the asset will be properly utilized and capable 
of providing valuable information. Successful tasking involves closing this gap. 
While this gap remains open, it may serve to support the position of those who 
would rather keep current tasking processes in place rather than seek innovative 
ways in which the tasking process might be improved. 

C. RESISTANCE TO CHANGE 

The suggestion that the goals of ORS may be advanced by reassessing 
the existing processes for tasking ISR satellites unavoidably indicts the current 
tasking processes. Such an indictment flies in the face of the apparently 
established view that the current tasking system is the desired methodology for 
tasking ORS assets. Deputy Undersecretary of Defense Thomas Behling 
directed that the tasking for the sensors carried on TacSat-2 “must come from 
established intelligence community mechanisms [2, p. 40].” This can easily 
be read as a wholesale endorsement of the current tasking process. 
Experimentation is essential to developing operational and responsiveness 
efficiencies for ORS. Constraining the tasking system to established processes 
limits the potential for a developmental initiative such as ORS. Mr. Behling 
arguably crushed any opportunity for innovative thinking with respect to tasking 
methodologies for TacSat-2. There is little unclassified information available to 
explain the logic behind such an edict, but one possibility is that politics played a 
role. 
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D. 


POLITICAL PRESSURE ON ISR SATELLITE TASKING 


Given the Presidential^ ordered requirement that U.S. intelligence assets 
serve multiple portions of the government besides the military [22], it is highly 
likely that politics may be a prime force in the tasking of assets. Take as an 
example another issue with TACSAT-2, which was launched in 2006 carrying 
multiple payloads including an imaging sensor [23] and a device for intercepting 
communications [23], [24], Several months after launch, those payloads had not 
been turned on. While the specifics are shrouded in secrecy, what is apparent is 
that there was a political and bureaucratic battle over the ownership of the 
mission of collecting intelligence, and the ownership of the data [25]. If political 
considerations can keep an entire payload on an ORS asset from even being 
activated, it seems no stretch that the same forces might easily exert influence 
over the tasking of those same assets. This is unlikely to please military 
commanders who believe they are not getting the support they require. 

Besides the perceived power contained in the ability to control the tasking 
of satellites, another explanation for the emphasis placed by the warfighter on the 
ability to directly task satellites may lie in the fact that the current overall ISR 
satellite infrastructure was not built to be military-specific. Cebrowski and 
Raymond argue in Operationally Responsive Space: A New Defense Business 
Model, that current ISR space assets are not designed for military use. They 
refer to the need to “tease” military utility from satellites that were designed with 
strategic needs in mind [26]. A look at Executive Order 12333, United States 
Intelligence Activities, clearly specifies in paragraph 1.1 that intelligence 
gathering activities of the U.S. government: 

Shall provide the President, the National Security Council, and the 
Homeland Security Council with the necessary information upon 
which to base decisions concerning the development and conduct 
of foreign, defense, and economic policies and the protection of 
United States national interests from foreign security threats. [22] 

The fact that intelligence gathering activities must service much more than 
military customers creates an unavoidable climate of competition for resources, 
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especially given the fact that resources are limited. This built-in tension was 
predicted by congress as far back as 1997 when the Intelligence Authorization 
Act report from the House of Representatives noted that: 

Competition for collection resources, in particular between 
immediate military requirements and longer-term national interests, 
is going to become increasingly fierce. [3] 

This is further indication that politics may play a central role in the tasking of 
overhead ISR assets. For military commanders at all levels, including the lowest 
echelon tactical units, the need to fight for their ISR satellite support in addition to 
fighting their adversary on the battlefield takes energy and resources away from 
their primary mission. It may also explain why Lieutenant General Campbell 
speaks of the Army looking to alternatives to satellites, which might be more 
easily controlled and tasked by the front-line commander [16]. 

E. CONTROL OF ISR SATELLITE TASKING 

Authority over ISR satellite tasking must be carefully placed. We have 
already determined that expertise is required to properly task an asset while 
taking into account the overall operational plan [27], Such expertise and 
awareness are not likely to exist in small forward units. The JRP experiment 
found that experienced collection managers had difficulties integrating the 
platform into their operations, casting significant doubt upon the ability of 
minimally trained personnel to manage the tasking of satellites. Given this 
precedent, ORS would appear to be a poor choice for delivering sensors that can 
easily and effectively be directly tasked by very low-level units. This can be 
directly attributed to the likelihood of a large gap between knowledge levels at 
those units and the knowledge levels required to manage ISR satellites. If the 
desire is to allow such low-level units to exercise tasking authority on ORS 
assets, this knowledge gap must be decreased. 

Two options should be considered. The less risky, but potentially more 
difficult and expensive option, involves ensuring all low-level units that might be 
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granted the opportunity to task satellites have personnel with the requisite 
knowledge for the job. An alternative option involves lowering the knowledge 
level required to task satellites successfully. By lowering the requisite knowledge 
level, more units may be capable of exercising tasking authority on ORS assets. 
In later chapters, this paper will discuss a tool that may be able to effectively 
lower the knowledge level and enable tasking authority to reside at lower levels. 
Despite the stated desire of commanders to directly control tasking of ISR 
assets, there is ample evidence that under current conditions this is neither 
practical nor effective. What is needed is a change in the overall approach to 
tasking of ISR satellites. 
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IV. OPERATIONALLY RESPONSIVE TASKING 


Operationally Responsive Tasking, or ORT, offers alternative ways to 
approach the problem of delivering responsiveness to military commanders. The 
concept of operationally responsive tasking does not define the ideal 
arrangement for tasking. Instead, it attempts to define some measures of 
responsiveness. These measures can be used to objectively assess the 
responsiveness of current or envisioned tasking systems. By defining basic 
measures of responsiveness, satellite operators and customers will have tools to 
aid them in assessing the overall responsiveness of a given tasking 
methodology. A key aspect of this is identifying customers who may be 
disadvantaged or overly privileged with respect to their ability to receive support. 
Several basic issues have been identified that may impact or enhance the ability 
of customers to receive their needed support. In addition to the concepts of 
Reactive Tasking and Proactive Tasking, the concepts of Tasking by Petition and 
Supplicant Tasking are introduced. They each carry unique implications for the 
responsiveness of a tasking system, and are designed to allow observers or 
planners better insight into the implications of various tasking methodologies. 

A. TASKING BY PETITION 

Tasking by Petition offers a simple model to approach the problem of 
managing collection on behalf of multiple agents using limited resources. This is 
a reasonable representation of the current intelligence community situation: 
There are numerous federal agencies or departments that require the services of 
collection platforms [22], and the desire for intelligence services often outstrip the 
available resources [14]. In order to assess the responsiveness of a tasking 
methodology, one option is to model it as Tasking by Petition. The general 
arrangement of organizations in Tasking by Petition involves a largely vertical 
relationship, with the collection asset located at the top, and the various entities 
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involved in the process occupying successively lower levels beneath the 
collection asset. Potential tasking flows from lower levels to higher levels, 
allowing the system to be characterized as a Tasking Ladder. 

Tasking by Petition includes several main players, including petitioners, 
gatekeepers, a tasking authority, technical execution agents, and the collection 
assets. Petitioners include any organization that is authorized to request 
intelligence information collection. There may be few or many petitioners, 
depending upon the policies set forth by parent organizations. Petitioners may be 
thought of as the reason for collecting intelligence and also the consumers of 
finished intelligence. 

1. Gatekeepers 

In the Tasking by Petition model, gatekeepers define rungs in the tasking 
ladder. Their function is to exercise triage on the tasking requests that are 
received from the next lower level on the tasking ladder. The requests are 
prioritized, and based upon the assigned priorities some are passed up to the 
next higher rung on the tasking ladder, where they may again be subjected to a 
triage process. Each level may have triage rules that are specific to that level, so 
a request may receive a high priority at several successive levels, only to face 
different rules at the next higher level and receive a low priority. In such an 
instance, the request may not be passed up to the next higher level in spite of 
high priority at lower levels. 

Without gatekeepers, the amount of tasking requests that would be sent to 
the technical execution agents, who exercise direct control of the collection 
assets, would be potentially overwhelming and force them into the role of 
gatekeeper, which is not the intent in this model. Depending on the overall 
tasking methodology, there may be few gatekeepers or many. It is noteworthy 
that different petitioners may have different numbers of gatekeepers between 
them and the technical execution agents. This would potentially make it more or 
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less difficult for them to get a tasking request into the queue for execution versus 
other petitioners. As we will see, this can serve as a valuable measure of 
responsiveness. 

2. Tasking Authority 

The Tasking Authority wields the authority to establish the utilization of an 
ISR asset and is the final gatekeeper in the system. The Tasking Authority has 
the final say on which taskings are elevated to the technical execution agents for 
actual execution on the asset. There may or may not be lower-level gatekeepers 
as well, whose purpose is to prioritize and filter requests from lower levels up 
towards the Tasking Authority. Technical Execution Agents occupy the next 
higher rung on the tasking ladder and maintain responsibility for exercising direct 
control over the collection assets. For ORS, these agents would likely be the 
satellite payload controllers who are responsible for sending commands and 
monitoring the performance of the payload. The collection asset occupies the top 
spot in the tasking ladder, as the final recipient of tasking. The collection asset, 
technical execution agent, tasking authority, gatekeepers, and petitioners all play 
unique parts in the overall model. Particularly important when assessing 
responsiveness are the relative positioning and numbers of the petitioners, 
gatekeepers, and tasking authority. 

B. TASKING DEPTH 

The petitioner-tasking model can be used to evaluate tasking processes 
that utilize triage at one or more levels. The first step to analyzing a tasking 
process is to identify the participants and place them into a diagram depicting 
their respective positions and roles. Figure 2 shows a very basic arrangement 
that reflects a simple tasking ladder. 
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ORS Satellite 



Petitioners are located at the bottom of this diagram and may be 
categorized by several methods. One method is to categorize them based upon 
the number of gatekeepers, including the Tasking Authority, between a petitioner 
and the Technical Execution Agents. We can refer to this number as the tasking 
depth associated with a given petitioner or group of petitioners. In Figure 2, there 
is only one gatekeeper between the petitioners and the satellite, giving this model 
a tasking depth of one. All of the petitioners reside at a tasking depth of one, but 
as we shall see, it is possible to have multiple levels with petitioners located at 
various levels. Tasking depth may vary from zero to n, depending on the number 
of gatekeepers in the model. Figure 3 displays a slightly more complicated 
situation with a total tasking depth of 2. 
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Tasking depth is a useful measure of the difficulty individual petitioners will 
have influencing the utilization of the satellite. The greater the number of 
gatekeepers between petitioner and technical execution agent, the less influence 
the petitioner is likely to have upon the actual use of the collection asset. This will 
give some insight into the responsiveness of the system for individual petitioners. 
The greater the tasking depth of a petitioner, the lower is the likelihood that the 
system will be responsive to that petitioner. By comparing the tasking depth of 
various petitioners and categorizing them based upon their tasking depth, we can 
identify potentially disadvantaged and privileged petitioners. 

Petitioners can be categorized in other ways as well, offering a better 
understanding of the community that seeks access to ISR assets. Such options 
for categorization may include, but need not be limited to, organizational level, 
combat capability, geographic area of operations, and type of unit. Such 

categorizations can make possible an analysis of the usage of ORS assets. 
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Additionally, it can offer the possibility of analyzing the types of units that are 
making requests for ORS ISR support, offering insight into which units may be 
otherwise ISR disadvantaged. Beyond understanding the demographics of units 
requesting and receiving ORS support, categorizing units can be very important 
when attempting to focus ORS support. By identifying units that fall into discrete 
categories, those units can be specifically targeted for support from ORS. This 
paper will discuss specific ways in which ORT can be used to focus such 
support. 

C. TASKING BREADTH 

In the effort to avoid excessive tasking depth, and its associated negative 
impact on responsiveness, it might seem advisable to decrease the number of 
tasking levels in the effort to limit tasking depth. If applied carefully, this method 
may serve to mitigate the negative impact of excessive tasking depth, but it 
carries some risks to responsiveness if not carefully executed. Assuming the 
same number of units (petitioners) are to be served, decreasing the number of 
levels will require concentration of petitioners upon fewer levels. Managing these 
more densely populated levels to maximize responsiveness may require multiple 
gatekeepers per level, or a greater concentration of petitioners per gatekeeper. In 
a diagram of this situation as seen in Figure 4, it becomes obvious why this is 
dubbed Tasking Breadth. 
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1. Tasking Breadth Tradeoffs 

In the diagram, the higher level clearly has a greater tasking breadth, 
while the lower level exhibits a low tasking breadth. The implications of tasking 
breadth on responsiveness become clear when we set up a comparison between 
two different ways to provide service to the same number of petitioners. A close 
examination of a simplified situation in which we seek to build a tasking ladder 
containing 50 petitioners shows how decreasing the overall tasking depth at the 
expense of tasking breadth can offer improvements up to a point. We will 
assume that the initial ladder has a tasking depth of 5, with ten petitioners at 
each level. The expected pass-through rate of each gatekeeper will be assumed 
to be only one task to maintain simplicity. Figure 5 depicts the structure and 
specifies the tasking depths. 
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Figure 5. Notional Tasking Structure with 50 Petitioners with a Maximum 
Tasking Depth of 5 


The lowest level will have a 1/10 pass-through, while all higher levels will 
have a 1/11 pass-through. We can calculate the overall odds of having a task 
make it to execution for each level as shown in Figure 6. 
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Figure 6. Depiction of Likelihood of Receiving Tasking Based Upon Tasking 
Depth 


It becomes apparent that increased tasking depth can quickly render units 
in the lower levels highly disadvantaged. In the notional situation above, units at 
a tasking depth of 1 are 13,310 times as likely as units at tasking depth 5 to 
receive tasking. This clearly places those units at the bottom of the tasking ladder 
in a severely disadvantaged position. One potential tactic to address this 
situation is to reduce the tasking depth. Keeping the original 50 petitioners in the 
model requires an increase in tasking breadth. If we limit the tasking depth to 2 
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and evenly divide the 50 petitioners between them, we end up with a tasking 
breadth of 25 petitioners per level. This situation has dramatic impact upon the 
likelihood of petitioners receiving tasking as shown in Figure 7. 



Figure 7. Modified Tasking Structure with 50 Petitioners and Maximum 
Tasking Depth of 2; Odds of Task Satisfaction Included on Right 


2. Impact of Modifying Tasking Breadth 

Increasing tasking breadth while decreasing tasking depth can be shown 
to greatly reduce the disparity in the odds of task satisfaction for the various 
petitioners. The worst-case odds of satisfaction went from 1 in 146,410 to a much 
larger 1 in 650. In this situation, the petitioners at a tasking depth of 1 are 25 
times more likely to receive tasking than those on the lowest level, a great 
improvement over the previous situation. If all petitioners were moved to a single 
level where tasking depth is one, then the overall odds reduce further to 1 in 50. 
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The downfall of this situation is that a single gatekeeper now has to evaluate a 
much larger number of requests for support, increasing overhead. Other 
problems arise as well. This one gatekeeper must now also find some way to 
manage triage amongst various missions and operational levels. This would 
arguably require an uncommon depth of knowledge for a higher-level 
organization to maintain. A third potential pitfall involves subordinate units 
submitting requests directly to the tasking authority, without coordination through 
their immediately superior units. This might lead to multiple redundant requests 
for collection as the units will not have insight into the requests made by their 
subordinate units. The single gatekeeper may shoulder the burden of resolving 
redundancies, which would be expected to increase workload and manning 
requirements. These complications potentially reduce the benefit of decreased 
tasking depth at the expense of increased tasking breadth. 
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V. GATEKEEPER TRIAGE RULESETS 


Gatekeepers must have methods for performing triage on the requests 
received from petitioners. A reasonable approach involves establishing basic 
rules for decision-making. In the ORT model, rulesets play a vital role in the 
overall tasking system. The rules adopted by gatekeepers determine the priority 
of requests and directly impact the likelihood that they will be elevated to the next 
higher rung on the tasking ladder. The interaction between gatekeeper rulesets 
and petitioner requests can be described using set notation and Venn diagrams. 

A. DESCRIBING RULESETS 

We start by defining all possible intelligence information as the Universal 
set, or U. Within that set, we define the subsets of information that petitioners 
believe are of concern for their assigned missions and for which tasking is 
requested. We designate another set comprised of the information that satisfies 
the triage ruleset adopted by the gatekeeper such that a high priority is assigned. 
For this discussion, we will assume one gatekeeper (G) and three petitioners (A, 

B, C). In the best-case scenario for responsive tasking, we find that all of the 
elements within sets A, B, and C are also elements in the gatekeeper’s set, G. 
This makes them subsets of G as shown in Figure 8. 
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The collection sets desired by the petitioners (A, B, C) 
satisfy the gatekeeper's triage rules (G). 


Figure 8. Venn Diagram Illustrating Situation in which Petitioners’ Desired 
Tasking Satisfies Gatekeeper's Triage Ruleset 

This is the preferred situation for responsiveness. The set of information 
that satisfies the gatekeeper’s triage ruleset (G) will not rule out any of the 
desired collection of the petitioners (A, B, C) by assigning them a low priority. A 
slightly less ideal situation arises when there is only partial overlap between the 
gatekeeper’s set and the sets of the petitioners. In this case, there is an 
intersection between the sets as shown in Figure 9. 
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Portions of the collection sets desired by the petitioners 
(A B, C) satisfy the gatekeeper's triage rules (G). 


Figure 9. Venn Diagram Depicting Situation in which Portions of Petitioners' 
Tasking Satisfies Gatekeeper's Triage Ruleset. 

Each of the notations above represents the elements that are shared 
between the gatekeeper and the petitioners. As long as the set represented by 
the intersection is not empty, there is commonality. For the tasking system, this 
indicates that at least some of the collection tasks desired by the petitioners are 
deemed valuable by the gatekeeper and have a chance of ultimately being 
tasked. One would expect that the tasks that fall outside of G will not be collected 
due to their failure to satisfy the triage rules established by the gatekeeper and 
their resulting receipt of low priority. It is possible to model an instance in which 
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there is no commonality between the set of acceptable collection and the desired 
collection sets of the petitioners. In the instance there is no commonality, the sets 
can be said to be disparate. Their intersection returns a null, or empty, set. 
Figure 10 depicts such a situation. 

A n G = {^} and B n G = {<f\ and C n G = {^} 

u 



The collection sets desired by the petitioners (A, B, C) 
do not satisfy the gatekeeper's triage rules (G). 


Figure 10. Venn Diagram Depicting Situation in which Petitioners' Desired 
Tasking Does Not Satisfy Gatekeeper's Triage Ruleset 

Where the petitioners’ desired collection does not intersect the collection 
that satisfies the gatekeeper’s ruleset, responsiveness is degraded. This is due 
to the fact that the gatekeeper’s triage rulesets amount to impediments to the 
ability of the units to “task an asset in real time” as desired by Lieutenant General 
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Campbell. We can identify the set of collection tasks desired by the petitioners as 
the union of their sets of desired collection tasks. 

AufiuC 

This specifies all tasks that are deemed desirable by the petitioners. We can also 
identify all tasks that do not satisfy the triage ruleset of the gatekeeper as the 
complement of G. 

~ G 

The intersection of these two sets identify the tasks that are desired by the 
petitioners but do not satisfy the ruleset of the gatekeeper. 

(AuBuC)n ~ G 

The ratio of this sum against the total tasks desired by the petitioners yields a 
measure of non-responsiveness in the specific rung of the tasking ladder. 

(AuBuC)n- G 
(AuBuC) 

To be operationally relevant, rulesets must be dynamic. As situations 
change on the battlefield, rulesets must flex in response. A static ruleset might 
quickly become useless in light of changing situations, focusing collection assets 
where they are not needed and reducing their overall usefulness. It is critical that 
organizations maintain the ability to quickly modify rulesets in response to 
changing needs. When such changes are required, they directly impact the ability 
of lower level petitioners to successfully elevate their tasking requests for 
execution. This may work in favor of the petitioners. In some instances, changes 
to rulesets may effectively block petitioners from receiving the tasking they 
require. 

B. SUPPLICANT TASKING 

Supplicant Tasking arises when the collection desired by a petitioner does 
not satisfy the triage ruleset of a gatekeeper. Supplicant Tasking represents a 
potential dysfunction in Petitioner Tasking that arises due to a mismatch between 
the mission concerns of petitioners and gatekeepers. As an example, a small 
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forward unit charged with securing a remote town may need some intelligence 
gathered to help them understand the local tactical situation. For the unit, this 
information is deemed critical to their ability to maintain control of the town. When 
they submit a tasking request to obtain this information, it goes up to the next 
higher-level gatekeeper, who tests it against their triage ruleset. Based upon the 
ruleset, they assign a priority to the task. In the event the tasking request is 
assigned a very low priority, it may be rejected and the petitioner is now faced 
with the problem of supplicant tasking. The dilemma here is clear. The unit 
requires this tasking to receive the information it is expected to gather, but the 
established rulesets make it nearly impossible to gain the cooperation of the 
gatekeeper. At this point, the unit must either give up on the tasking request, or 
develop some method to convince the gatekeeper to accept the task. This might 
take the form of humbly requesting the task be approved (supplicating) or 
otherwise convincing the gatekeeper that their triage ruleset was not properly 
developed or applied. In either case, the need to engage in extended dialogue in 
order to receive the tasking they need degrades the responsiveness of the 
overall system. 

Supplicant tasking may arise in a situation where a gatekeeper has limited 
responsibility, or no responsibility, for the mission of one or more petitioners. This 
lack of responsibility may be expected to influence the ruleset of the gatekeeper 
to the detriment of one or more petitioners. We theorize that the more removed 
the gatekeeper is from the petitioner on the tasking ladder, the more likely that 
this situation will occur. If the gatekeeper has no responsibility for the missions of 
any petitioners, it may have difficulty developing a coherent triage ruleset. Under 
such circumstances, the application of a triage system may be problematic 
without external guidance in the development of the ruleset. Lacking outside 
guidance, it is difficult to determine whose mission is more important, placing the 
onus for convincing the gatekeeper firmly into the lap of the petitioners. It is this 
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need to convince an uninvoived party of the worthiness of a particular mission 
and its associated collection requirements that transforms the petitioners into 
supplicants. 

A slightly different situation arises when a gatekeeper has responsibility 
for only some of the missions of petitioners. In such a case, the disenfranchised 
petitioners are not only transformed into supplicants, they are disadvantaged 
supplicants relative to the other petitioners who have a mission shared with the 
gatekeeper. They have to convince the gatekeeper, who has a direct interest in 
the missions of one or more other petitioners, that they should divert those 
resources to a mission for which the gatekeeper has no responsibility. This is 
unlikely to meet with success unless the asset is underutilized or unnecessary for 
the success of the gatekeeper’s missions. 

One possibility to remedy the potential issues with Supplicant Tasking 
involves moving the Tasking Authority down to a level where petitioner and 
gatekeeper missions maintain enough similarity to drive the development of 
triage rulesets that benefit all petitioners. There is no guarantee that petitioners 
will receive their taskings, but the triage rulesets will likely not automatically 
disqualify their desired taskings. This approach may tend to drive tasking 
authority lower on the tasking ladder, decreasing tasking depth. Using this 
approach to identify dysfunction between petitioners and gatekeepers may help 
with a determination of the appropriate level at which to place tasking authority to 
maximize responsiveness. 

To avoid Supplicant Tasking, the mission responsibilities for various levels 

must be carefully examined to ensure that they are at least partially reliant on 

petitioners beneath them in the tasking ladder. Since this approach may indicate 

a need to move the Tasking Authority down the ladder, it also has the benefit of 

decreasing the Tasking Depth, which should also increase the efficiency and 

responsiveness of the overall tasking system. The exception to this is for higher 

level petitioners who are cut off from the ability to task the asset as the Tasking 

Authority moves to levels beneath them on the tasking ladder as depicted in 
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Figure 11. An extreme example of this might include moving tasking authority for 
an ISR satellite from the National Intelligence Community level down to a theater 
brigade level. This would remove demand for resources that would otherwise 
keep tactical users from accessing the satellite for battlefield support. 



Figure 11. Diagram Demonstrating Movement of Tasking Authority to Lower 
Level Gatekeeper 

The decision to remove higher-level petitioners from the tasking ladder 
has the impact of focusing the asset upon lower level petitioners. The tradeoff 
here is clear: to improve the situation for the lower level petitioners, the higher- 
level petitioners have been deprived of the use of the asset. Such a move may 
seem draconian when only a single asset is considered. In a real-world situation, 
we assume that multiple assets are involved, each with their own tasking ladder. 
Within the model for a single asset, moving the tasking authority to a lower level 
appears to leave higher-level units totally unsupported. Factoring the assumed 
presence of additional assets and their associated tasking ladders reveals that 
the situation has multiple options for servicing all petitioners. 
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Another criterion for placement of the tasking authority involves expertise. 
As was demonstrated by the JRP experiment, expertise is necessary to 
successfully manage the tasking for an ISR asset. Placing the tasking authority 
too far down in an organization may place it at a level where the requisite 
expertise is not typically resident. The lack of expertise will effectively increase 
the gap between the knowledge level of the tasking authority and the requisite 
knowledge necessary to properly task the asset. This need to minimize the 
knowledge gap will tend to place the Tasking Authority higher in the tasking 
ladder where the requisite expertise to manage a collection asset is more likely to 
be found, unless a way can be found to push expertise to lower units, or 
decrease the expertise needed to effectively minimize the requisite expertise. 
Another argument for moving the Tasking Authority higher on the tasking ladder 
involves the desire to make the asset available to as many units as might be able 
to benefit from the capabilities it possesses. The desire to service as many units 
as possible comes with a price, however, which is a loss of responsiveness for 
individual units. 

C. TASKING COMPETITION 

Inherent in all tasking situations where demand exceeds available 
resources is competition. The number of competitors who all seek the use of a 
single asset can offer insight into the likely average level of responsiveness for 
any individual competitor. This is a simple matter of available assets being 
divided up amongst the units who would like to use them. If we look at a single 
rung on the tasking ladder, we should be able to identify the number of units (n ) 
who are capable of requesting tasking of the asset. This number includes 
gatekeepers from lower levels who are elevating a task to the current level, 
essentially acting as petitioners at the higher level. The chance that any single 

unit will have use of the asset would be represented as —. The issue becomes 

n 

somewhat more complicated when we consider multiple rungs on the tasking 
ladder. In such a situation, assuming each gatekeeper offers an even chance to 
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their immediate petitioners, we must use basic methods for computing 
probability. Specifically, we must multiply the odds presented at each level a 
request must pass through. In this case, we seek the probability that a tasking 
request will be accepted and passed up the ladder at every level from its origin to 
the top of the ladder. We find that the likelihood of receiving tasking (and by 
extension responsiveness) decreases drastically with each successive step down 
the ladder. Specifically, the relationship can be shown as: 

till 

— X-X-...-. 

77 , 77 2 77 2 ll x 

where n x is equal to the number (77) of petitioners at the given level (x). This 

number quickly diminishes as the tasking depth increases. While this method 
may be slightly flawed in its assumption that all potential petitioners will submit 
requests and that they will all request the same amount, it does show the basic 
idea that tiered tasking systems can quickly put lower units at a great 
disadvantage. 

To more accurately identify the decreasing odds of receiving tasking as 
tasking depth is increased, the triage rulesets must be included. In the basic 
model for ORT, is it assumed that all gatekeepers have the authority to develop 
and implement their own rulesets. If each gatekeeper maintains this autonomy, 
the importance of the tasking structure has a significant impact on the odds of a 
task making it to execution. If gatekeepers do not act independently, but instead 
adopt similar rulesets, the impact of the process structure can potentially be 
nullified. If the rulesets at each rung of the tasking ladder define certain tasks as 
high priority, they will stand a high chance of execution regardless of their 
positioning in the tasking ladder. The basis for such favor might be rooted in unit 
identity, mission type, geographic area, or other factors surrounding the tasking 
request. To assess the impact on responsiveness, we must examine how the 
various gatekeepers adopt similar rulesets. 
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Consider a situation in which gatekeepers at multiple levels independently 
agree on similar priorities for certain tasks. In such a situation, responsiveness 
for lower echelon units will be enhanced, at least for those particular tasks. A 
more problematic situation occurs when a high-level gatekeeper dictates all or 
part of their subordinate gatekeepers’ rulesets. Unless the high-level gatekeeper 
is dictating rulesets specifically to favor low-level petitioners, the dictated rulesets 
are unlikely to benefit lower echelon units. Responsiveness for lower echelon 
units will be degraded. Lieutenant General Campbell clearly believes that lower 
echelon units are deprived of intelligence [16]. One potential cause is the 
development and implementation of higher echelon triage rulesets that discount 
the importance of lower echelon needs for intelligence. We have already 
theorized that the more removed a gatekeeper is from a petitioner, the more 
likely that supplicant tasking will occur. This suggests that filtering low echelon 
units through high echelon rulesets will negatively impact responsiveness. It may 
prove impossible for lower echelon units to receive tasking when the request 
conflicts with higher echelon gatekeepers’ rulesets. To deliver responsiveness in 
such a situation, tasking authority must be moved to a level lower than the 
interfering rulesets. 

The power of rulesets as de facto filters on tasking requests is nearly 
absolute. While rulesets may be devised to mandate inclusion of lower echelon 
requests, the dynamic nature of rulesets may render such situations temporary. 
Any gatekeeper between a petitioner and the tasking authority may adopt a 
ruleset that blocks that petitioner’s requests. Moving tasking authority to lower 
levels on the tasking ladder can minimize the likelihood of such a blockage, 
increasing the responsiveness of the system for the petitioner. 

To best manage responsiveness, an awareness of both tasking process 
structure and triage rulesets must be maintained. Given the power of rulesets, 
one might believe that they should be the main mechanism for managing 
responsiveness. When managing responsiveness using only rulesets, the 
different concerns of gatekeepers at various organizational and tasking levels 
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may heavily bias responsiveness towards the higher echelons. This coincides 
with the assertion that lower echelon units are deprived of intelligence support 
and the ability to task assets. By using adjustments to tasking process structure, 
specifically by managing the level of the tasking authority, it is possible to 
mitigate the impact of higher echelon rulesets and deliver responsiveness to 
units at lower echelons. 

D. TRIAGE WITH MULTIPLE MISSIONS 

One potential impact of increasing tasking breadth is the potential to 
concentrate petitioners with different missions under a single gatekeeper. The 
greater the tasking breadth, the more likely this becomes. Also heightened with 
increased tasking breadth is the possibility for even greater disparity in the nature 
between the missions concentrated underneath a single gatekeeper, increasing 
the odds that some petitioners will be forced into Supplicant Tasking. The issue 
that potentially arises in such a situation is how to perform triage with multiple, 
disconnected missions. In the case of triage with a single mission, such as might 
be encountered in an emergency department where the mission is centered 
around fixing broken people, triage rules will arguably not be complicated by the 
pursuit of differing outcomes. Comparisons between like units or missions is 
arguably a relatively straightforward process compared to comparisons to 
disparate missions or units [28]. Triage may become somewhat more 
complicated when it is applied to multiple, non-connected missions. Rather than 
making a set of rules designed to improve the mission effectiveness for a single 
mission, the addition of multiple missions requires the introduction of 
methodologies to assess when one mission will benefit at the expense of 
another, separate mission. Lacking these methodologies, the constancy of the 
tasking process may suffer, bringing in an element of uncertainty that can be 
damaging to the overall system. 
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VI. FOCUS ON THE WARFIGHTER 


The ORT model offers insight into the ramifications of tasking process 
design choices. Such ramifications will directly impact the ability of users to 
leverage the tasking system to support their missions. For existing tasking 
systems, the ORT model can guide modification of basic aspects of a tasking 
structure to tailor the delivery of responsiveness. This paper had intended to 
discuss how modification of a tasking process structure might “focus 
responsiveness” upon specific units in an effort to avoid spreading asset 
availability across all possible units, thereby degrading responsiveness for all of 
them. A closer examination of the issue revealed that the idea of “focusing 
responsiveness” resulted in a redundancy. It became clear that, in the case of a 
tasking system, responsiveness and focus might be so closely linked that any 
attempt to separate them becomes nonsensical. 

A. FOCUS AND TRIAGE 

Focus underlies the concept of triage. The most basic triage described in 
this paper includes three levels of priority: patients who must have immediate 
attention, patients who can wait for attention, and patients for whom attention will 
make no difference in their medical outcome. Prioritizing patients in such a 
fashion serves one purpose: to focus energy and resources upon those areas 
which will most positively impact mission accomplishment. The converse holds 
relevance as well: to minimize or remove energy and resources from those areas 
which will least positively impact the mission. Additional numbers of triage 
categories, or priorities, such as those being recommended by the U.S. 
Department of Health and Human Services for medical triage [19], do not change 
this situation. Instead, they increase the specificity of any adjustments to focus 
that may be accomplished using the triage methodology. Where ORT comes into 
play is identifying privileged and disadvantaged petitioners. 
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Methods for identifying privileged and disadvantaged petitioners were 
introduced within the Petitioner Tasking model. It was shown that the 
arrangement of the tasking process could be modified to equalize inequities 
imposed by design choices. Such modifications include alterations to tasking 
depth, tasking breadth, and the option of implementing gatekeeper rulesets with 
the intent of giving advantage to specific petitioners, ostensibly based upon one 
or more unit traits. All of these techniques unavoidably involve engineering 
inequities between petitioners. Invoking the concept that responsiveness may 
hinge upon the ability to focus the services of assets upon specifically chosen 
petitioners highlights the potential that a tasking system with both privileged and 
disadvantaged petitioners may increase responsiveness for some, but not for all. 
In order for responsiveness to increase for one, it must diminish for another. 
Treating responsiveness as a finite resource properly frames the problem of 
building a responsive tasking system. Rather than searching for an artful 
application of tasking methodology to increase responsiveness across all 
petitioners, we must acknowledge that decisions must be made about which of 
the petitioners will receive the focus of the tasking process, and by extension, 
responsive support. 

B. RESPONSIVENESS AS A LIMITED RESOURCE 

Responsiveness is not unbounded. It is tied to the capacity of a system. 
The hardware and infrastructure of an ISR system define its capacity. A poorly 
designed tasking process may prevent a system from performing to its capacity 
but even an ideal tasking process cannot push a system beyond capacity. It can 
maximize performance within the system’s capacity. Just as the hardware and 
infrastructure of an ISR system limit its capacity, the capacity of a system limits 
the responsiveness available from the system. If the tasking system is improperly 
constructed, then the responsiveness of a system will suffer. This was observed 
at St. Joseph’s emergency department. It is in the careful delivery of responsive 
capabilities that a tasking system can enhance the overall responsiveness of a 

system. It cannot increase it beyond its limits. 
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Revisiting the assertions of Lieutenant General Campbell, we find that his 
definition of responsiveness includes the ability to directly task an asset. This 
implies no competition and no sharing. The General wants warfighters to have 
the asset available for their use, without competition. This is the most responsive 
an asset can be from a tasking perspective: if the asset is physically available 
and capable, then it can be tasked. A unit will only experience this level of 
responsiveness in the absence of competition from others. Since responsiveness 
is a limited quality associated with an asset, any subdividing of the asset across 
multiple users will reduce the responsiveness to each of those users. An analysis 
of the previously presented concept of tasking depth will help explain the concept 
of limited responsiveness. Two tasking systems were presented, each 
encompassing 50 petitioners, but utilizing different distributions of the petitioners 
and different tasking depths. It was shown that the difference in probability of 
receiving service from the asset decreased dramatically as tasking depth 
increased. What was not highlighted was the fact that the sum of the odds for 
each petitioner in the process equals exactly the number of potential taskings for 
the asset. This must always be the case. The methodology for determining the 
probability is a process of successively dividing and distributing the asset’s 
potential for tasking. All of the potential is used, as shown in Figure 12, unless 
specifically discarded. 
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Finite System 
Capacity (C) 


1CV11 of C used, 1/11 
passed down as R1 


10/11 of R1 used, 1/11 
passed down as R2 


10/11 of R2 used, 1/11 
passed down as R3 


10/11 of R3 used, 1/11 
passed down as R4 

All of R4 used 

Figure 12. Illustration of Potential Distribution of System Capacity 

System capacity, designated as C in the diagram above, represents the 
limitations the system has on delivering services to petitioners. Attempts to 
increase C fall outside the realm of ORT, which deals only with methods for 
understanding how tasking can impact responsiveness of an overall system and 
its impact upon specific petitioners. Increasing capacity of the system is not a 
tasking issue. We have demonstrated, however, that a tasking system can be 
designed in such a way as to significantly limit the responsiveness of a system, 
regardless of capacity, much in line with the experience at St. Joseph’s hospital. 
The key to success is identifying the best arrangement for a tasking process, and 
identifying where tasking authority should reside. 
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C. EQUILIBRIUM 

The models presented offer conditions under which tasking authority 
should be pushed lower on the overall tasking ladder, and conditions under 
which it should be elevated on the tasking ladder. Given these competing 
influences, it should be possible to identify an equilibrium where arguments on all 
sides come to impasse, a theoretical best location for tasking authority. This may 
not be possible without a significant amount of collection infrastructure to ensure 
that the required tasking of all units can be satisfied. Lieutenant General 
Campbell’s definition of responsiveness reads in part “the ability to task an asset 
in real time.” Unless there are adequate assets on hand to ensure that units can 
task when they need based upon their operational situation, it is unlikely that any 
positioning of tasking authority will be able to deliver the ability the General 
wants. 

This is not a surprise, as an equilibrium point is likely to offer the best 
average responsiveness to users. While this has some merit, it may not meet the 
needs of the warfighter. We would have to alter the general’s statement to read, 
“increased odds of being able to task an asset in real time.” Arguably, if the units 
cannot count upon the support they need, it is unlikely that they will consider the 
system responsive. A more controlled approach to managing the responsiveness 
of ORS assets might involve focusing the responsiveness of assets upon 
individual units. 

D. MANAGING FOCUS 

The key to delivery of responsiveness is the ability to focus 
responsiveness on units that require it most, whether due to their mission, 
geographic location, or other demographics. The basic understanding delivered 
by the ORT model gives multiple ways to engineer focus. Responsiveness is 
limited and cannot be delivered as a blanket to the entire population of potentially 
needy units or mission. Under this constraint, the ability to consciously target 
specific units, geographic areas, or missions assumes greater relevance. 


47 



Consider that the general concept for ORS includes a decision point where a 
need for support is established [1, p. 4] and this becomes clear. The idea that 
tasking for ORS assets might not carefully focus upon the issue that gave rise to 
the need for support clearly departs from logic. The question is not whether a 
tasking process should be tailorable and focused, but how best to tailor a tasking 
process to achieve the desired focus. This is a key impetus for the development 
of ORT and its supporting constructs. 

If we accept the premise that concentrating, or focusing, the ability to 
directly access collection assets such as satellites delivers responsiveness, we 
must then understand how best to create and manage that focus. We have 
shown that the structure of a tasking process can significantly impact the 
responsiveness available to petitioners. We have also shown how modifications 
to a tasking process can alter the responsiveness of the system for specific 
petitioners. The measures discussed can offer options and techniques for 
managing the distribution of responsiveness to intelligently enhance the services 
rendered to specific units. 

The key to focusing responsiveness lies in the willingness and ability to 
make decisions about which units will be singled out to receive increased access 
to an asset, thus increasing the odds that they will be able to task the asset when 
desired with little to no interference introduced by the tasking process. It must be 
noted that impediments to a unit’s ability to task an asset that are rooted in other 
issues outside of the tasking process, such as hardware issues, orbital 
constraints, etc., are not considered a factor within ORT. The focus is exclusively 
upon the aspects of operations that can be controlled by modifying or otherwise 
adapting the processes surrounding tasking. The best a tasking process can do 
is to deliver the amount of responsiveness available from any given asset or 
system. 

In order to focus responsiveness, there must be certain infrastructure 

components as well as organizational flexibility in the distribution of requisite 

technical and intelligence expertise. The crux of this issue is the gap between 
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resident expertise and requisite expertise to properly manage the asset at the 
level where tasking authority would otherwise best be positioned. One option is 
to deliver the expertise to that level in the form of personnel transfer. Another 
option is to potentially reduce the requirement for resident knowledge. As will be 
shown in the next chapter, VMOC has potential to become a tool to accomplish 
just that. 
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VII. IMPLEMENTING ORT WITH VMOC 


In Chapter II, it was shown that ORS is using VMOC as a tool to plug into 
the existing tasking processes utilized by COCOMs and JFCs. This approach is a 
rapid solution, but it fails to fully capitalize on VMOC’s capabilities. The 
capabilities included in VMOC, if fully developed, promise to enable management 
and control of the tasking process in ways that align well with the concepts of 
ORT. 

A. APPORTIONMENT OF ASSETS 

Apportionment is among the most intriguing and powerful capabilities 
envisioned for VMOC. This concept involves the ability to grant users, or 
petitioners in the ORT model, access to direct the use of operational assets. The 
system includes the ability to control the specific use of the asset based upon a 
“control authority policy.” This policy serves to establish and maintain limits on 
the authority of individual units [29]. Applying this ability to the ORT model, it 
becomes apparent that this could offer an effective method for controlling tasking 
depth by lowering the tasking authority to an appropriate level. This would also 
concentrate the use of the asset at that level, ensuring that the delivery of 
responsiveness was not in doubt. Units would understand the access that they 
have to the asset and could command it within a specified scope. 

The ability to apportion assets allows the use of both reactive and 
proactive tasking. Either the apportionment authority can use the system in a 
reactive sense, awaiting requests for support and comparing them to their 
existing triage rulesets before apportioning the asset, or they can project the 
anticipated need for the assets and apportion the assets to allow units to utilize 
them as the need arises. The ability to use both methods arguably maximizes the 
utility and flexibility of the overall system. 
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B. TASKING LADDER VISUALIZATION 


Given the fact that VMOC is a web-based system requiring password or 
other authentication to enable access [30, p. 4], and as such, must track users, 
the opportunity exists for VMOC to build and maintain accurate depictions and 
statistics on the structure of the tasking ladder. Under the current approach used 
for VMOC, where it is plugged into existing theater tasking tools, the structure 
would be expected to be extremely simple with few gatekeepers or petitioners. It 
would still offer insight into the advantages and limitations of the structure. If 
VMOC were extended to lower echelon units within the command, the tools could 
become very illuminating. 

One of the keys to understanding the tasking environment is the ability to 
graphically map and evaluate the overall tasking process. By producing a 
graphical map of the overall tasking hierarchy, users and commanders could 
easily evaluate the existence of potentially privileged and disadvantaged users. 
Such maps would allow easy assessments of tasking depth and tasking breadth. 
Additionally, the system could include tags on users including geographic area, 
missions assigned, or other demographic information to help understand how the 
tasking system might be biased with respect to real-world considerations. 

Perhaps most importantly, the ability to visualize the tasking process can 
offer commanders the capability to engineer the system to focus on those units, 
missions, or geographic areas of greatest concern. Without the ability to clearly 
understand the tasking process, engineering the desired focus of assets upon 
specific units becomes potentially more challenging. This lack of understanding 
could arguably result in instances where units are inadvertently placed at a 
disadvantage, harming the overall mission. By offering a visualization tool, 
commanders can quickly and easily see how changes impact the ability of 
specific units to receive access to ISR assets that would most benefit their 
mission. 
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While VMOC could be modified to map out the tasking structure, it cannot 
do so unless access is extended to all units that may want to submit a tasking 
request. As was shown in Chapter I, the current use of VMOC seems to extend 
no further than into the highest levels of the COCOM/JFC organizational 
structure. To truly capitalize upon the ability of VMOC to identify and map the 
tasking process, VMOC must extend down to lower echelon petitioners, with 
intermediate gatekeepers between them and the COCOM/JFC level. Such an 
extension of VMOC could offer multiple benefits to units. 

C. KNOWLEDGE GAP MITIGATION 

Just as VMOC might offer the capability to better understand the tasking 
process of an organization, it can also help units to better understand the 
capabilities and limitations offered by ORS assets. Such a capability is essential 
to narrowing the knowledge gap required to make best use of ORS assets. This 
is a key requirement to ensure that assets can be freely apportioned to units 
without concerns about their ability to properly utilize them. One option to ensure 
that units have the requisite knowledge to use an ORS asset involves the 
assignment of personnel with expertise. Such an approach is potentially 
expensive and time-consuming, attributes that conflict with the basic premises of 
ORS, which include low cost and rapid delivery of capabilities [1]. Alternatives 
involve identifying methods by which the need for expertise is reduced. VMOC, 
as the interface for users of ORS, might be engineered to help less 
knowledgeable users identify how best to use ORS assets, including which 
capabilities are appropriate for specific needs. Users of typical computers are 
familiar with the “Wizards” built into the software. The Wizards are carefully 
crafted to help users navigate some of the more technical aspects of operating or 
managing their computers. Such a concept might be employed within VMOC to 
enable less experienced units understand how best to utilize the capabilities 
provided by ORS assets. This is especially true in the case of proactive tasking 
where units are provided an asset for use and must identify the best utilization for 
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that asset. Even in the case of reactive tasking, such an enhancement may be 
useful to units as they evaluate what type of capability they might require. One 
way to help deliver this is to incorporate ontologies into VMOC. 

D. ONTOLOGIES 

The incorporation of ontologies into VMOC may help units better 
understand the capabilities they are requesting and how to best match them to 
their collection needs. Ontologies have been proposed as a viable approach to 
matching ISR assets with tasks required by users [31]. Of particular interest to 
this approach is the possibility for ontologies to help mitigate the issue of poor 
communication, which may be driven by “different needs and background 
contexts [31, p. 2].” Such a situation may arise between petitioners and 
gatekeepers, especially with greater tasking breadth or in a supplicant tasking 
scenario. As stated in An Ontology-Based Approach to Sensor-Mission 
Assignment 

People, organizations, and software systems need to communicate 
and share information, but due to different needs and background 
contexts, there can be widely varying viewpoints and assumptions 
regarding what essentially the subject matter is. The lack of shared 
understanding leads to poor communications between people and 
their organizations, severely limits systems interoperability, and 
reduces the potential for reuse and sharing. Ontologies aim at 
solving the former problems. [31, p. 2] 

Definitions of ontologies vary. A useful definition is “formal models of the 
various elements that can be used with deductive reasoning mechanisms to 
produce matches that are logically sound [31, p. 1].” Figure 13 illustrates how 
ontologies describe the attributes of a platform. Various potential capabilities of 
the platform are identified. When applied to a sensor, these form a basic ontology 
by modeling the elements of the platform. Ontologies can be made more specific. 
This would be accomplished by delving deeper into the description of the 
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platform, identifying technical attributes that make it suitable for the tasks listed in 
the diagram. For the purposes of assigning sensors, the listed attributes may be 
entirely adequate. 


Platform Capabilities 
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% ArtilleryAdjustment 
4 Damage Assessment 
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Figure 13. Lists of Attributes Used to Build Ontologies for Sensor Platforms 
(From Presentation Slides for An Ontology-Based Approach to 
Assigning Sensors to Tasks [32]) 


An ontology’s ability to identify a platform’s capabilities in discrete 
attributes, referenced in basic language, increases shared understanding of the 
platform. A technical expert on the platform may prefer to discuss specific details 
such as frequencies, orbital altitude, field of regard, etc. These may be of little 
use to the warfighter who seeks to understand the utility of the platform. Such 
differences arise from the differing points of view of the warfighter and the 
technical expert. By creating an ontology to define the platform in terms usable 
by both the technical expert and the warfighter, a shared understanding may 
arise. This shared understanding can be the basis for improved communication 
and improved utilization of the asset. Taking this concept further, semantic 
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matching relations can be established and rendered graphically [31, 32], This 
further simplifies communications between parties and can increase 
understanding of the platform. Figure 14 gives examples of simple graphical 
representations of semantic matching relations between a mission and candidate 
sensors. 
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Figure 14. Graphical Representation of Semantic Matching Relations Between 
Sensor and Mission (From Presentation Slides for An Ontology- 
Based Approach to Assigning Sensors to Tasks [32]) 


The ability to graphically show the level of service that sensors can offer 
may reduce the expertise needed to understand their suitability for a mission. In 
Figure 13, SI can be shown to exactly match the necessary requirements (Q). 
S5, which has a disjoint match, is easily understood to be unsuitable. S2, S3, and 
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S4 each have some utility for the mission, but also come with tradeoffs. S2 and 
S4 each partially satisfy the mission requirements. S3 and S4 meet either part of 
the requirements (S4) or all of the requirements (S3) but each brings capabilities 
in excess of the requirements. Such graphical representations can help those 
who might seek to use the assets but lack in-depth technical knowledge. 

Ontologies may be structured in such a way that they can be programmed 
into computers. A good target for this is VMOC. Utilizing the textual and graphical 
approaches available through ontologies may allow VMOC to improve 
communication between petitioners and gatekeepers. By creating shared 
understandings of tasking requirements and options, efficiency and effectiveness 
of the tasking process may be improved. The ability to make ontologies machine- 
processable and “mediating among different people and systems” [31, p. 2] may 
augment the ability to push tasking authority to deeper levels without increasing 
the expertise resident at those levels. This is due to the ability of ontologies to 
generate simplified representations of complex relationships. Adding such 
functionality to VMOC could greatly enhance the ability of ORS to provide 
services to all levels of command, regardless of their resident expertise. 
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VIII. CONCLUSIONS AND RECOMMENDATIONS 


A. HARDWARE FIXATION 

The ORS community appears to be following historical precedent and 
focusing upon developing hardware and software solutions while largely ignoring 
potential changes to operational processes. In the case of ORS, improvements to 
the tasking process may have a positive impact on responsiveness. Improving 
hardware and infrastructure may not improve performance, as illustrated by the 
experience at St. Joseph’s emergency department. When the department 
improved its processes, performance improved dramatically. Similarly, improving 
satellite-tasking processes may improve their ability to be responsive to the 
warfighter. Based upon most current unclassified information, ORS tasking 
improvements are largely hardware, software, and infrastructure oriented. Given 
the apparent dearth of study dedicated to development of basic tenets for tasking 
satellites, it is not surprising that established tasking processes, rather than more 
innovative options, are being applied to ORS. The seemingly rigid support of the 
community for the established National-level tasking system does not bode well 
for the ability of ORS to break out and develop a military-centric, focused tasking 
system. 

B. ISR TASKING 

Satellite tasking may be described as a triage process. Such a process 
involves the development and application of rules to prioritize requests for 
collection. The prioritization is then used to assign tasks to assets. Expertise is a 
requirement for successful triage. The more of a gap between the expertise of 
the individuals involved in the process and the required knowledge, the less 
successful the system will be. 

Expertise is not the only barrier to setting up an optimized triage system 
for ORS. Political pressures exist to keep the existing systems in place and apply 
them to ORS. Current intelligence gathering satellites are not specifically military 
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oriented. Instead, they serve much more than the military, and as such have 
many competing demands on their resources. This leads to a problem for the 
military, as the control of satellites may not reside within the military. 

Mapping out the current National Intelligence tasking ladders as they 
extend to low-echelon military units may prove illuminating. We have shown that 
the nation’s intelligence infrastructure does not specifically focus on the military, 
but instead is mandated to support multiple portions of the government. 
Competition for resources may be graphically represented using the basic ORT 
model. Such a depiction may also illuminate the reasons that military 
commanders have requested the development and implementation of ORS. 
Whether military or civilian, the ability of the ORT model to identify privileged and 
disadvantaged petitioners may offer insight into the strengths and shortcomings 
of the United States’ overall intelligence tasking processes. 

C. ORT 

ORT’s basic approaches to modeling and characterizing the structure of a 
tasking process can give insight into how organizational arrangements and 
process structure can impact the ability of units to receive tasking. By graphically 
depicting the structure of a system, it is possible to begin understanding the 
relationships between those who would make use of the system and those who 
control access to the system. Further, once those relationships are understood, 
the ability to identify privileged and disadvantaged users offers the ability to 
ensure that responsiveness is being delivered in support of the commander’s 
objectives. 

Three main characteristics of ORT were identified: tasking depth, tasking 
breadth, and triage rulesets. Tasking depth and tasking breadth are reflections of 
the structure of the tasking process. It was shown that modifications of these 
characteristics could greatly impact the relative ability of units to receive tasking 
from the system. Triage rulesets act as filters within the system by determining 
the priorities assigned to tasking requests. In the event that tasks encounter 
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triage rulesets that assign them a very low priority, a phenomenon call supplicant 
tasking may occur. This represents a potential dysfunction within the tasking 
process and places units at great disadvantage in obtaining support. Such a 
situation may require modification of the tasking structure. 

By modifying the relationships or structure of the overall tasking process, 
the commander can specifically target units with responsiveness in accordance 
with operational needs. In particular, the ability to grant specific units tasking 
authority can ensure that the units most in need of support are able to receive it. 
By pushing tasking authority deeper into the tasking ladder, it is possible to avoid 
filtering the requests of lower echelon units through the rulesets of high echelon 
organizations. There are limitations that can impact the ability of a commander to 
effectively deliver responsiveness to specific units. Most notable is the need for 
expertise to allow the units to make the best use of their access to the assets. In 
the lack of expertise, a knowledge gap may become evident that will undermine a 
unit’s ability to make use of assets. 

D. FOCUSING RESPONSIVENESS 

Responsiveness is limited. It is directly tied to the capacity of a system. 
Delivering responsiveness to lower echelon units is limited by the capacity of the 
system. It is possible to attempt to evenly distribute responsiveness across all 
possible units, but this appears to run counter to the desires of the warfighter as 
voiced by Lieutenant General Campbell. A more satisfactory solution is to focus 
the services of assets upon specific units or organizations, ensuring them the 
ability to task as necessary. Such a solution requires leadership willing to make 
decisions about which units will receive such services and which units will not. 

E. IMPLEMENTING ORT WITH VMOC 

As a tool for tasking, VMOC possesses the potential to directly focus 

responsiveness upon chosen units via apportioning tasking authority to specific 

users. The addition of a capability to model the overall tasking process, with 

emphasis on the relationships between units, can deliver a powerful visualization 
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tool to assess which units in the process may be overly privileged or 
disadvantaged. Finally, the distributed nature of VMOC and its use by all units 
involved in the process postures it as an ideal platform to simplify an 
understanding of the proper use of ORS assets. By embracing the established 
approach of building “wizards” to help computer users through some of the more 
technical aspects of various programs, VMOC could close down the knowledge 
gap that currently poses an impediment to units who would otherwise benefit 
from direct access to space assets. Additionally, the incorporation of ontologies 
into VMOC may help further reduce the knowledge gap. Ontologies can 
represent the capabilities and uses for satellite assets in ways that deemphasize 
in-depth technical specifications. By characterizing assets in operationally 
relevant terms, users will have better understandings of how to request and 
direct collection assets. 
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IX. AREAS FOR FURTHER RESEARCH 


In Chapter VI, the limited nature of responsiveness was presented. 
Spreading responsiveness equally among all possible units may not meet the 
warfighter’s desire for baseline responsiveness for any single unit. Previous 
research that directly aligns with this concept has been accomplished in 
Assigning Sensors to Missions with Demands [33]. This research relates directly 
to sensor assignment and offers interesting mathematical approaches to 
understand the issues involved. Most notably, it is interested in determining a 
lowest level of support that will be accepted as valuable. Lesser levels of support 
receive “no credit for partially satisfied missions.” Application of this approach to 
extend the ORT model may be valuable by defining the minimum service an 
ORS asset must give to a unit in order to be considered responsive. 

A different avenue for research is contained in A Knapsack Approach to 
Sensor-Mission Assignment with Uncertain Demands [34]. The authors in this 
paper apply the Knapsack Problem to determine the best usage of sensors 
without exceeding a defined limit. Such an application may be complementary to 
the approach in Assigning Sensors to Missions with Demands. Combined, they 
may define the upper and lower limits for optimum petitioner service for ORS 
assets. They may also offer the ability to determine appropriate petitioner levels 
to which ORS assets might be applied. If an ORS asset has less available 
responsiveness than is necessary to satisfy the responsiveness needs of a target 
unit, it might best be focused upon a lower echelon or entirely different unit. Or it 
might require the combined efforts of several ORS satellites to deliver the 
minimum responsiveness necessary to earn the “credit” discussed in Assigning 
Sensors to Missions with Demands. 
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